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Abstract 

We  address  why,  and  especially  how,  to  represent 
business  rules  in  e-commerce  contracts.  By  con- 
tracts, we  mean  descriptions  of  goods  and  services 
offered  or  sought,  including  ancillary  agreements 
detailmg  tenris  of  a  deal.  We  observe  that  rules 
are  useful  in  contracts  to  represent  conditional  rela- 
tionships, e.g.,  in  terms  &  conditions,  service  provi- 
sions, and  surrounding  business  processes,  and  we 
illustrate  this  point  with  several  examples. 
We  analyze  requirements  (desiderata)  for  repre- 
senting such  rules  in  contracts.  The  require- 
ments mclude:  declarative  semantics  so  as  to  en- 
able shared  understanding  and  interoperability;  pri- 
oritized conflict  handling  so  as  to  enable  modu- 
lar updating/revision;  ease  of  parsing;  integration 
into  WWW-world  software  engineering;  directe  x- 
ecutabihty;  and  computational  tractability. 
We  give  a  representational  approach  that  consists 
of  two  novel  aspects.  First,  we  give  a  new  fun- 
damental knowledge  representation  formalism:  a 
generalized  version  of  Courteous  Logic  Programs 
(CLP),  which  expressively  extends  declarative  or- 
dinary logic  programs  (OLP)  to  include  prioritized 
conflict  handling,  thus  enabling  modularity  in  spec- 
ifying and  revising  rule-sets.  Our  approach  to  im- 
plementing CLP  is  a  courteous  compiler  that  trans- 
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forms  any  CLP  into  a  semantically  equivalent  OLP 
with  moderate,  tractable  computational  overhead. 
Second,  we  give  a  new  XML  encoding  of  CLP, 
called  Business  Rules  Markup  Language  (BRML), 
suitable  for  interchange  between  heterogeneous 
commercial  rule  languages.  BRML  can  also  ex- 
press a  broad  subseto  f  ANSI-draft  Knowledge  In- 
terchange Format  (KIF)  which  overlaps  with  CLP, 
Our  new  approach,  unlike  previous  approaches, 
provides  not  only  declaratives  emantics  but  also 
prioritized  conflict  handling,  ease  of  parsing,  and 
integration  into  WWW-world  software  engineer- 
ing. We  argue  that  this  new  approach  meets  the 
overall  requirements  to  a  greater  extent  than  any 
of  the  previous  approaches,  including  than  KIF,  the 
leading  previous  declarative  approach. 
We  have  implemented  both  aspects  of  our  ap- 
proach; a  free  alpha  prototype  called  Common- 
Rules  was  released  on  the  Web  in  July  of  1999,  at 
http : //alphaworks . ibm. com. 

An  extended  version  of  this  paper  will  be  avail- 
able as  afo  rthcoming  IBM  Research  Report  (at 

http  :  //www.  research  .  ibm.  com). 

1     Introduction 

One  form  of  commerce  that  could  benefit  substantially  from 
automation  is  contracting,wh  ere  agents  form  binding.a  gree- 
able  terms,  and  then  execute  these  terms.  By  "agents",  we 
mean  initially  parties  in  the  Economics  sense,  e.g.,  as  buyers 
or  sellers;  however,  once  automated,  these  agents  might  be 
intelligent  agents  in  the  Computer  Science  sense. 


By  e-commerce  "contracts",  we  mean  in  a  broad  sense:  de- 
scriptions otgoods  and  services  offered  or  sought,  along  with 
applicable  terms  &  conditions,  i.e.,  ancillary  agreements  de- 
tailing teniis  of  a  deal.  Such  terms  include  customer  service 
agreements,  delivery  schedules,  conditions  for  returns,  usage 
restrictions,  and  other  issues  relevant  to  the  good  or  service 
provided. 

Such  descriptions  are  to  be  found  in  catalogs  and  store- 
fronts, as  well  as  in  bids  and  requests  communicated  (e.g.,  by 
agents)  during  negotiations,  procurements,  and  auctions. 

The  overall  contracting  process  comprises  several  stages, 
including  broadly: 

1 .  Discovery:  Agents  find  potential  contracting  partners. 

2.  Negotiation:  Contract  terms  are  detemiined  through  a 
process  of  communication  between  agents,  often  involv- 
ing iterative  modification  of  the  contract  terms. 

3.  Execution:  Transactions  and  other  contract  provisions 
are  executed  by  the  agents. 

We  observe  that  many  contract  terms  involve  conditional 
relationships,  and  can  conveniently  be  expressed  as  rules,  of- 
ten called  business  nileso  r  business  policies.  (Sometimes, 
"business  rule"  is  used  to  mean  any  kind  of  significant  ap- 
plication logic,  e.g.,  the  algebraic  formula  for  computing  an 
insurance  annuity.  By  "rule"  in  this  paper,  we  mean  more 
specifically  an  implication  (i.e.,  IF-THEN)  in  which  the  an- 
tecedent (i.e.,  the  IF  part)  may  contain  multiple  conjoined 
(i.e.,  AND'ed)  conditions.) 

For  example,  rules  are  useful  in  describing: 

•  terms  &  conditions,  e.g.,  rules  for  price  discounting; 

•  service  provisions,  e.g.,  rules  for  refunds;  and 

•  surrounding  business  processes,  e.g.,  rules  for  lead  time 
to  place  an  order. 

(Section  2  elaborates  on  these  examples.)  We  believe  that 
rules  as  an  overall  representational  approach  capture  well 
many  aspects  of  what  one  would  like  to  describe  in  automated 
contracts. 

In  this  work  we  are  concerned  primarily  with  the  negotia- 
tion stage  of  contracting,  and  specifically  with  how  to  repre- 
sent business  rules  in  contracts. 

The  contract  terms  may  or  may  not  be  modified  during  the 
negotiation  stage.  If  not,  the  negotiation  stage  may  be  a  rel- 
atively simple  process  of  communication  followed  by  accep- 
tance. Crucial  during  negotiation,  however,  is  thatal  1  agents 
must  understand  and  agree.  In  terms  of  automation,  the  con- 
tract has  to  be  communicated  and  digested  by  each  agent, 
with  shared  semantics.  (More  generally,  some  agents  might 
be  human,  as  well  as  automatic;  however,  the  aspects  of  hu- 
man interaction  are  beyond  the  scope  of  this  paper.) 

Our  goal  is  a  shared  language  with  which  agents  can  reach 
a  common  understanding  of  rules  in  contracts,  such  that  the 
rules  are  relatively  easily  modifiable,  communicatable,  and 
executable  by  the  agents. 


Note  that  we  make  a  sharp  distinction  between  the  repre- 
sentational mechanism  for  communicating  contract  rules,  and 
the  actual  rule  execution  mechanisms  employed  by  partici- 
pating agents.  Our  concern  here  is  with  the  former,  though  of 
course  in  designing  a  communication  mechanism  one  must 
consider  and  anticipate  the  requirements  of  execution  to  be 
performed  by  each  of  the  agents. 

We  will  take  a  declarative  approach  to  business  rules  in 
contracts.  By  "declarative"  semantics  for  rules,  we  mean 
in  the  sense  of  knowledge  representation  (KR)  theory,  in  a 
manner  abstracted  away  from  the  choice  ofim  plementation 
approach:  the  semantics  say  which  conclusions  are  entailed 
(e.g.,  model-theoretically)  by  a  given  set  of  premises,  with- 
out dependence  on  procedural  or  control  aspects  of  inference 
algorithms.  In  particular,  declarative  semantics  abstract  away 
from  whether  the  direction  of  rule  inferencing  is  backward 
versus  forward. 

2     Example  Roles  for  Rules  and  Prioritized 
Conflict  Handling 

Next,  we  give  a  few  brief  examples,  expressed  in  natural  lan- 
guage, of  business  rules  in  contracts.  As  we  go,  we  will  see 
both  the  need  for  prioritized  conflict  handling  —  because  of 
conflict,  and  the  opportunity  for  prioritized  conflict  handling 
—  because  of  naturally  available  prioritization  information. 

Example  1  (Refund  Policy) 

A  typical  example  of  a  seller's  refund  policy  is: 

•  (Rule  A:)  "If  buyer  returns  the  purchased  good  for  any 
reason,  within  30  days,  then  the  purchase  amount,  minus 
a  10%  restocking  fee,  will  be  refunded." 

•  (Rule  B:)  "If  buyer  returns  the  purchased  good  because  it 
is  defective,  within  I  year,  then  the  full  purchase  amount 
will  be  refunded." 

•  (Priority  Rule:)  "If  both  Rules  A  and  B  apply,  then 
Rule  B  'wins',  i.e.,  the  full  purchase  amount  will  be  re- 
fiinded". 

Here,  we  say  a  rule  "applies"  when  that  rule's  body  (i.e.,  an- 
tecedent) is  satisfied.  The  Priority  Rule  is  necessary  because 
it  can  happen  that  the  buyer  returns  the  good  because  it  is  de- 
fective within  30  days.  In  this  case,  Rules  A  and  B  conflict 
with  each  other;  both  rules  apply  but  their  consequents  are 
incompatible  with  each  other.  The  conflict  is  resolved  by  pri- 
ority: Rule  B  is  specified  to  have  higher  priority  than  Rule  A. 

Example  2  (Lead  Time) 

In  business-to-business  commerce,  e.g.,  in  manufacturing 
supply  chains,  sellers  often  specify  how  much  lead  time,  i.e., 
minimum  advance  notice  before  scheduled  delivery  date,  is 
required  in  order  to  place  or  modify  a  purchase  order.  An 
example  of  a  parts  supplier  vendor's  lead  time  policy  is: 

•  (Rule  A:)  "14  days  lead  time  if  the  buyer  is  a  preferred 
customer." 


•  (Rule  B:)  "30  days  lead  time  if  the  ordered  item  is  a 
minor  part." 

•  (Rule  C:)  "2  days  lead  time  it":  the  ordered  item's  itein- 
type  is  backlogged  at  the  vendor,  and  the  order  is  a  mod- 
ification to  reduce  the  quantity  of  the  item,  and  the  buyer 
is  a  preferred  customer." 

•  (Prioriis  Rule:)  "II'  Rules  A  and  C  both  apply,  then  Rule 
C  'wins',  i.e. ,2  days  lead  time," 

The  rationale  for  Rule  C  is  that  the  vendor  is  having  trouble 
filling  its  overall  orders  (from  all  its  buyers)  for  the  item,  and 
thus  IS  pleased  to  have  this  buyer  relieve  the  pressure. 

Rules  A,  B,  and  C  may  conflict:  two  or  three  of  them  might 
appK  to  a  given  purchase  order.  The  Priority  Rule  provides 
partial  prioritization  information  -  its  rationale  might  be  that 
Rule  C  is  more  specific,  or  more  recent,  than  Rule  A.  How- 
ever, the  above  rule-set  leaves  unspecified  how  to  resolve  con- 
flict between  Rules  A  and  B,  for  example;  no  relative  priority 
between  them  is  specified  as  yet.  This  reflects  a  common  sit- 
uation when  rules  accumulate  over  time,  or  are  specified  by 
multiple  authors:  at  any  given  moment  during  the  process  of 
incremental  specification,  there  may  be  insufficient  justified 
priority  to  resolve  all  potential  conflicts. 

Example  3  (Bookstore  Personalized  Discounting) 

Sellers  often  provide  personalized  price  discounting.  A  topic 
of  considerable  interest  today  among  e-commerce  sellers  is 
how  to  do  this  more  cheaply  and  uniformly  by  automating  it. 
An  e.xample  of  a  bookstore's  personalized  discounting  policy 
is: 

•  (Rule  A:)  "5  percent  discount  if  buyer  has  a  history  of 
loyal  spending  at  the  store." 

•  (Rule  B:)  "10  percent  discountif  buyer  has  a  history  of 
big  spending  at  the  store." 

•  (Rule  C:)  "5  percent  discount  if  buyer  has  a  store  charge 
card." 

•  (Rule  D:)  "10  percent  discount  if  buyer  is  a  member  of 
the  store's  Platinum  Club." 

•  (Rule  E:)  "No  discountif  buyer  has  a  late-payment  his- 
tory during  the  last  year." 

•  (Priority  Rules:)  "B  is  higher  priority  than  all  the  oth- 
ers; D  is  higher  priority  than  A  and  than  C;  E  is  higher 
priority  than  A  and  than  C  and  than  D." 

Here,  the  Priority  Rules  specify  a  set  of  priority  comparisons, 
that  are  sufficient  to  resolve  all  the  potential  conflicts  among 
the  rules. 

More  Example  Roles  for  Rules 

We  believe  that  many  contract  terms  can  be  well  represented 
as  rules. 

•  Policies  about  cancelling  orders  are  often  similar  in  feel 
to  the  examples  above  about  refunds  and  lead  time. 


•  Policies  about  discounting  for  groups  or  preferred 
customer  organizations,  e.g.,  hotel  discounts  for  AAA 
members,  are  often  similar  in  feel  to  the  example  above 
about  personalized  discounting. 

•  In  supply  chain  settings:  requests  for  proposals,  and  re- 
sponding bids,  often  involve  conditional  relationships 
between  price,  quantity,  and  delivery  date,  e.g.,  "If 
the  order  quantity  is  between  400  and  1000  units,  and 
the  delivery  date  is  between  15  and  30  daysfro  m  the 
order  date,  then  the  price  is  $48  per  unit.". 

•  In  product  catalogs,  many  properties  of  a  product  are 
most  naturally  specified  as  conditional  on  other  proper- 
ties of  that  product,  rather  than  being  particular  to  an  in- 
dividual product.  E.g.,  "all  laptop  computers  include  an 
internal  modem".  E.g.,  "all  women's  T-shirts  are  avail- 
able in  sizes  XS,  S,  M,  and  L",  "all  men's  T-shirts  are 
available  in  sizes  S,  M,  L,  XL,  and  XXL",  and  "all  T- 
shirts  are  available  in  colors  navy,  khaki,  and  black". 
E.g.,  "all  V-neck  sweaters  are  available  in  fabrics  acrylic 
and  cashmere". 

•  Policies  about  creditworthiness,  trustworthiness,  and 
authorization  are  often  naturally  expressed  in  terms  of 
sufficient  and/or  necessary  conditions.  Such  conditions 
include:  credentials,  e.g.,  credit  ratings  or  professional 
certifications;  third-party  recommendations;  properties 
of  a  transaction  in  question,  e.g.,  its  size  or  mode  of  pay- 
ment; and  historical  experience  between  the  agents,  e.g., 
familiarity  or  satisfaction. 

3     Rule  Representations:  Previous  Approaches 
including  KIF,  Requirements  Analysis 

In  section  1,  we  stated  that  in  this  work  our  goal  is  a  shared 
language  with  which  agents  can  reach  a  common  under- 
standing of  rules  in  contracts,  such  that  the  rulesa  re  rela- 
tively easily  modifiable,  communicatable,  and  executable 
by  the  agents. 

In  this  section,  we  analyze  and  elaborate  these  require- 
ments (i.e.,  criteria  or  desiderata,  which  we  bold-face 
throughout  this  section)  for  a  rule  representation,  and  discuss 
candidate  previous  approaches  in  light  of  them,  as  motiva- 
tion for  our  approach.  We  begin  by  reviewing  previous  ap- 
proaches. 

There  are  multiple  approaches  already  in  wide  imple- 
mented commercial  use  for  representing  business  rules  gen- 
erally (not  for  contracts  in  particular).  One  approach  is  di- 
rectly as  if-then  code  constructs  in  general-purpose  imper- 
ative programming  languages  such  as  C,  C++,  and  Java'. 
Other  approaches  are  more  specific  to  rules.  A  second  ap- 
proach is  Prolog  [3],  a  programming  language  oriented  to- 
wards backward-chaining  rules.  A  third  approach,  closely  re- 
lated to  Prolog,  is  SQL  views.  In  SQL-type  relational  database 
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systems  [22]  a  view  is  defined,  in  eflect,  by  a  set  of  rules.  A 
fourtli  approach,  fairly  closely  related  to  SQL  views,  is  eveni- 
coiiJiiion-action  rules  I  "active  rules"  /  "triggers"  [22]  of  the 
kind  found  in  many  database  systems  and  routing  systems. 
These  are  forward-directed,  triggered  by  events  such  as  up- 
dating a  database  relation.  A  fifth  approach  is  production 
rules,  a  form  of  forward-chaining  rules,  of  the  kind  in  sys- 
tems descended  from  the  0PS5  system  [4].  There  are  other 
approaches  as  well,  e.g.,  in  expert  systems,  knowledge-based 
systems,  and  intelligent  agent  building  tools,  but  the  above- 
listed  are  probably  the  currently  most  commercially  impor- 
tant, especially  m  e-commerce. 

A  sixth  approach  for  representing  business  rules  is  Knowl- 
edge Interchange  Format  (KIF)^.  KJF  is  not  a  directly  ex- 
ecutable representation.  Rather,  KIF  is  a  language  for  in- 
terchange of  knowledge,  including  rules,  between  heteroge- 
neous software  systems,  e.g.,  agents.  More  precisely,  KIF  is 
a  prefix'  version  of  first-order  predicate  calculus  (i.e.,  first- 
order  classical  logic)  with  extensions  to  support  the  "quote" 
operator  (thus  enabling  additional  expressiveness  akin  to  that 
of  classical  higher-order  logic)  and  definitions.  KJF  is  cur- 
rently well  along  in  the  ANSI  standards  committee  process. 
Supporting  or  endorsing  KIF  is  also  being  considered  infor- 
mally in  several  other  standards  efforts  relevant  to  agent  com- 
munication, e.g.,  FIPA^'.K  IF,  however,  is  not  yet  in  wide  im- 
plemented commercial  use. 

Next,  we  elaborate  on  requirements  and  relate  them  to  the 
previous  approaches.  One  group  of  requirements  revolves 
around  heterogeneity.  Specifically,  the  multiplicity  of  widely 
implemented  approaches  implies  an  immediate  requirement 
to  cope  with  heterogeneity  of  implementations  of  busi- 
ness rules.  The  ability  to  communicate  with  shared  under- 
standing then  implies  the  requirements  of  interoperability 
with  declarative  semantics.  The  above-listed  widely  imple- 
mented approaches  lack  fully  declarative  semantics. 

Communicatability  and  interoperability  imply  the  require- 
ment of  ease  of  parsing  rule-sets  that  are  being  communi- 
cated. Interoperability  and  practical  executability  imply  the 
requirement  of  integration  into  WWW-world  software  en- 
gineering overall.  The  XML  aspect  of  ourapp  roach  facili- 
tates such  parsing  and  integration. 

A  second  group  of  requirements  revolves  around  expres- 
siveness. A  basic  overall  requirement  is  expressive  power  in 
specifying  rules.  Practical  executability,  however,  implies  the 
strong  desire  for  computational  tractability  in  the  sense  of 
average-case  and  worst-case  complexity.  Expressive  power 
has  to  be  balanced  against  tractability. 

^http : //logic . Stanford. edu/kif /  and 
http : //www. cs . umbo .edu/kif/ 

^The  current  draft  ANSI  specification  of  KIF 
(http : //logic . Stanford. edu/kif /dpans .html)  also 
includes  an  infix  version  of  KIF  intended  for  human  consumption 
rather  than  automated  exchange. 
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Ease  of  modifiability  implies  the  requirement  of  expres- 
sive convenience  for  the  process  of  specification.  Expressive 
convenience  is  in  part  an  aspect  of  expressive  power,  but  also 
implies  the  need  for  conceptual  naturalness  of  semantics. 

An  important  aspect  of  expressive  power  is  the  ability  to 
conveniently  express  rules  that  are  logically  non-monotonic, 
i.e.,  rules  that  employ  negation-as-failure  or  are  default  rules. 
In  particular,  it  is  important  to  conveniently  express  pri- 
oritized conflict  handling,  i.e.,  where  some  rules  are  sub- 
ject to  override  by  higher-priority  conflicting  rules,  such  as 
by  special-case  exceptions,  by  more-recent  updates,  or  by 
higher-authority  sources.  As  we  saw  in  our  contract  rule-set 
examples  in  section  2,  conflict,  and  the  need/opportunity  for 
prioritized  override,  frequently  arise. 

Most  commercially  important  rule  systems  (including  the 
above-listed  widely  implemented  approaches)  employ  non- 
monotonic reasoning  as  an  essential,  highly-used  feature. 
Typically,  they  employ  some  form  of  negation-as-failure.  Of- 
ten they  employ  some  forni  of  prioritized  override  between 
rules,  e.g.,  the  static  rule  sequence  in  Prolog  or  the  computed 
rule-activation  sequence/"agenda"  in  0PS5-heritage  produc- 
tion rule  systems. 

In  modern  software  design,  it  is  widely  recognized  that  a 
vital  aspect  of  modifiability  ismod  ularity  and  locality  in 
revision,  e.g.,  in  the  manner  that  subclassing  and  informa- 
tion hiding  provide  in  object-oriented  programming.  Prior- 
itized conflict  handling  enables  significantly  easier  modifi- 
cation and  more  modular  revision/updating.  New  behavior 
can  be  specified  more  often  by  simply  adding  rules,  without 
needing  to  modify  the  previous  rules.  E.g.,  a  more  specific- 
case  rule  can  be  added  and  given  higher-priority  than  a  previ- 
ous general-case  rule,  without  needing  to  modify  the  general- 
case  rule.  This  is  similar  to  the  modular/local  gracefulness 
in  object-oriented  programming  of  adding  a  subclass  without 
needing  to  modify  the  superclass. 

Another  important  aspect  of  expressive  power,  in  rela- 
tion to  practical  executability,  is  the  ability  to  conveniently 
express  procedural  attachments.  Procedural  attachments 
are  the  association  of  procedure  calls  with  belief  expres- 
sions, e.g.,  in  Example  1,  the  association  of  the  Java  method 
CustomerAccount .  setCredi tAmount  with  the  logi- 
cal predicate  refund.  Procedural  attachments  are  crucial  in 
order  for  rules  to  have  actual  effect  beyond  pure-belief  in- 
ferencing,  e.g.,  forac  tions  to  be  invoked/performed  as  a  re- 
sult after  rule  conclusions  are  inferred.  Procedural  attach- 
ments are  also  very  useful  to  invoke  procedure  calls  when 
rule  conditions  are  tested/queried.  Almost  all  of  the  above- 
listed  widely  implemented  approaches  include  procedural  at- 
tachments. 

However,  procedural  attachments  are  semantical  ly  prob- 
lematic, and  an  open  research  issue  today  is  how  to  give  them 
a  semantics  that  abstracts  away  from  implementation  details 
and  is  thus  akin  to  being  declarative.  (See  the  discussion  of 
Situated  Logic  Programs  in  section  5.) 


K.IF  has  been  developed  specifically  for  puqioses  of  com- 
munication, in  response  to  the  need  to  cope  with  implemen- 
tational  heterogeneity  of  rules  and  other  knowledge.  By  con- 
trast with  the  abo\e-listed  widely  implemented  approaches, 
KIF  has  a  fully  declarative  semantics;  indeed,  that  is  its  main 
intended  strength.  Its  declarative  semantics  is  based  on  clas- 
sical logic,  primarily  focusing  on  first-order  logic.  First-order 
logic  is  logically  monotonic,  highly  expressive,  and  compu- 
tationally intractable  (to  perform  inferencing)  for  the  general 
case 

KIF  can  express  a  broad  class  of  rules.  However,  it  has 
several  important  shortcomings  as  a  language  for  business 
rules  in  e-commerce,  including  in  contracts.  Perhapsm  ost 
crucially,  KIF  has  a  shortcoming  of  its  fundamental  knowl- 
edge representation  (KR):  it  cannot  (conveniently)  express 
logical  non-monotonicity,  including  negation-as-failure,  de- 
fault rules,  and  prioritized  conflict  handling;KI  F  is  logically 
monotonic.  KIF  also  cannot  (conveniently)  express  procedu- 
ral attachments;  it  is  a  pure-belief  KR.  KIF  has  been  designed 
with  an  orientation  towards  knowledge  as  a  non-executable 
specification  as  much  or  more  than  towards  knowledge  as  ex- 
ecutable. Also,  the  KIF  effort  has  focused  more  on  a  highly 
inclusively  expressive  representation  than  on  ease  of  develop- 
ing translators  in  and  out  of  that  representation  (this  is  some- 
thing the  XML  aspect  of  our  approach  improves  upon). 

In  our  \ievv.  none  of  the  above-listed  previous  approaches 
to  representing  business  rules,  nor  any  other  previous  ap- 
proach that  we  are  aware  of,  satisfactorily  meets  the  whole  set 
of  requirements  we  listed  above  (in  bold-face).  In  particular, 
the  widely-implemented  approaches  above  lack  sufficiently 
declarative  semantics;  KIF,  though  declarative,  lacks  logical 
non-monotonicity. 

KIF's  declarative  approach  does,  however,  inspire  us  to  de- 
velop our  own  declarative  approach. 

4     A  New  Declarative  Approach  to  Rules: 
Courteous  Logic  Programs  +  XML 

The  approach  is  to  choose  Ordinary  Logic  Programs  (OLP) 
—  in  the  declarative  sense  ([  1  ]  provides  a  helpful  review),  not 
Prolog  —  as  a  fundamental  KR,  plus  to  embody  this  KR  con- 
cretely in  XML  for  purposes  of  communication  between  the 
contracting  agents.  '  Logic  programs  are  noton  ly  relatively 
powerful  expressively,b  ut  also  practical,  relatively  computa- 
tionally efficient,  and  widely  deployed. 

We  expressively  extend  the  approach's  declarative  fun- 
damental KR  formalism  to  be  Courteous  Logic  Programs 
(CLP).  CLP  expressively  extends  Ordinary  Logic  Programs 
to  include  prioritized  conflict  handling,  while  maintaining 
computational  tractability.  CLP  is  a  previous  KR  [10]  which 


"Ordinary"  logic  programs  are  also  sometimes  known  as  "gen- 
eral" (e.g.,  in  [1])  or  "normal"  logic  programs,  or  as  (the  declarative 
version  of)  "pure  Prolog". 


we  have  here  further  expressively  generalized,  notably  to  han- 
dle pairwise  mutual  exclusion  conflicts,  rather  than  simply 
conflicts  of  the  form  p  versus  -ip. 

4.1     First  KR  Step:  Ordinary  Logic  Programs 

We  begin  defining  our  approach  by  choosing  the  fundamen- 
tal KR  for  rules  to  be:  declarative  Ordinary  Logic  Programs 
(OLP),  with  the  well-founded  semantics  (WFS)  [23],  inhially 
expressively  restricted  to  the  predicate-acyclic  case  (defined 
below).  (Henceforth,  we  will  leave  "declarative"  implicit.) 
This  is  a  "pure-belief"  KR,  i.e.,  it  lacks  procedural  attach- 
ments. 

Each  rule  in  an  OLP  has  the  form: 

Ao      <-      Ai  /\   .  .  .   h  Am  /\  ~^m+l  A    ...   A  ~An. 

Here,  n  >  m  >  0,  and  each  A,  is  a  logical  atom.  Aq  is  called 
the  head  (i.e.,  consequent)  of  the  rule;  the  rest  is  called  the 
body  (i.e.,  antecedent)  of  the  rule.  If  the  body  is  empty,  the 
<—  may  be  omitted.  A  ground  rule  with  empty  body  is  called 
a  fact.  ~  stands  for  the  negation-as-failure  operator  symbol, 
and  is  read  in  English  as  "fail".  Intuitively,  ~p  means  that  p 
is  not  believed  to  be  true,  i.e.,  that  p's  truth  value  is  either 
false  or  unknown. 

E.g.,  the  first  rule  in  Example  2  might  be  written  as: 
order  Modi  ficationNotice{'?Order,  day  sli) 
<—    pre  ferredCustomerO  f  {?  Buyer ,  ISeller) 
A  purchaseOrderClOrder,  ? Buyer,  ? Seller) . 
Here,  the  prefix  "?"  indicates  a  logical  variable. 

Ordinary  LP's  have  been  well-studied,  and  have  a  large  lit- 
erature (reviewed,  for  example,  in  [I]).  For  several  broad  but 
restricted  expressive  cases,  their  (declarative)  semantics  is  un- 
controversial:  e.g.,  for  the  predicate-acyclic,  stratified,  locally 
stratified,  and  weakly  stratified  cases;  these  form  a  series  of 
increasing  expressive  generality.  However,  OLP's  have  prob- 
lematic semantics  for  the  unrestricted  case,  due  essentially 
to  the  interaction  of  recursion  with  negation-as-failure.  "Re- 
cursion" here  means  that  there  is  a  cyclic  (path  of  syntactic) 
dependency  among  the  predicates  (or,  more  generally,  among 
the  ground  atoms)  through  rules.  More  precisely,  a  logic  pro- 
gram S's  predicate  dependency  graph  PDGs  is  defined  as 
follows.  The  vertices  of  the  graph  are  the  predicates  that  ap- 
pear in  S.  {p,q)  is  a  (directed)  edge  in  PDGs  iff  there  is  a 
rule  r  in  £  with  p  in  its  head  and  q  in  its  body.  "Predicate- 
acyclic"  means  that  there  are  no  cycles  in  the  predicate  depen- 
dency graph.  "Stratified"  (in  its  various  flavors)  means  cycles 
of  a  restricted  kind  are  allowed. 

The  well-founded  semantics  is  probably  the  currently  most 
popular  semantics  for  the  unrestricted  case,  and  is  our  fa- 
vorite. With  WFS,  the  unrestricted  case  always  has  a  single 
set  of  conclusions,  and  is  tractable  under  commonly-met  re- 
strictions (e.g.,  VBD  defined  below). 

Our  approach  for  an  initial  practically-oriented  LP-based 
business  rules  KR  is,  however,  to  keep  to  expressively  re- 
stricted cases  that  have  uncontroversial  (i.e.,  consensus  in  the 
research  community)  semantics  —  starting  with  predicate- 


acyclic.  Compared  to  these  uncontroversial  cases,  the  unre- 
stricted case  (e.g.,  with  WFS)  is  more  complex  computation- 
ally and,  perhaps  even  more  importantly,  is  more  difficult  in 
terms  of  software  engineering,  lireq  uires  more  complicated 
algorithms  and  is  not  widely  deployed.  The  predicate-acyclic 
expressive  restnction  can  be  checked  syntactically  with  a  rel- 
atively simple  algorithm  and  with  relatively  low  computa- 
tional cost. 

An  OLP  (with  WFS)  consists  of  a  set  of  premise  rules,  and 
entails  a  set  of  (primitive)  conclusions.  In  a  predicate-acyclic 
OLP,  each  conclusion  has  the  form  ofa  ground  atom.  Intu- 
itively, each  conclusion  atom  is  believed  to  be  true,  and  every 
other  (i.e.,  non-conclusion)  ground  atom  is  not  believed  to  be 
true  (recall  ~  above). 

Next,  we  discuss  the  advantages  of  OLP's  (with  WFS). 
(.\dv  1):  OLP  has  a  fully  declarative  semantics  that  is  use- 
ful and  well-understood  theoretically.  (Adv  2):  OLP  in- 
cludes negation-as-failure  and  thus  supports  basic  logical 
non-monotonicity.  (Adv  3):  OLP  has  considerable  expres- 
sive power,  yet  is  relatively  simple  and  is  not  overkill  expres- 
sively. (Adv  4):  OLP,  unlike  first-order-logic/KIF,is  compu- 
tationally tractable  in  the  following  sense.  Under  commonly 
met  expressive  restrictions,  e.g.,  VBD,  inferencing  —  i.e., 
rule-set  execution  —  in  OLP  can  be  computed  in  worst-case 
polynomial-time.  Here,  we  say  that  an  LP  is  ''VBD"  when 
either  (a)  it  is  ground,  or  (b)  it  has  no  logical  fijnctions  of 
non-/^ero  arity  (a.k.a.  the  Daialog  restriction^)  and  it  has  a 
bounded  number  of  logical  variables  appearing  in  each  rule. 
By  contrast,  classical  logic,  e.g.,  first-order  logic  —  and  thus 
KIF,  is  co-NP-hard  under  the  VBD  restriction.  (Adv  5):  We 
observe  predicate-acyclic  OLP's  semantics  is  widely  shared 
among  many  commercially  important  rule-based  systems  as 
an  expressive  subset  of  their  behavior.  Prolog  is  the  most 
obvious  family  of  such  systems.  Relational  databases  are  an- 
other such  family;  many  SQL  view  definitions  (and  relational 
algebra  operations)  are  in  effect  OLP  rules.  0PS5-heritage 
production  rule  systems  are  less  closely  related  because  of 
their  extensive  use  of  procedural  attachments,  but  insofar 
as  they  commonly  do  pure-belief  predicate-acyclic  inferenc- 
ing, their  semantics  is  closely  related  to  forward-directed 
OLP's.  Event-condition-action  rules  are  somewhat  similar  in 
this  regard  to  a  simple  form  of  production  rules.  Other  sys- 
tems sharing  the  semantics  include  many  expert/knowledge- 
based  systems  and  intelligent  agent  building  tools;  many  of 
these  implement  forward-directed  predicate-acyclic  OLP's. 
Predicate-acyclic  OLP  semantics  thus  reflects  a  consensus  in 
the  rule  representation  community  that  goes  beyond  the  logic 
programming  community.  (Adv  6);  Predicate-acyclic  OLP's 
are,  in  effect,  widely  implemented  and  deployed,  including  in 
Prolog's  and  SQL  relational  databases,  but  also  beyond  them. 


"■It  is  usually  straightforward  to  representationally  refomiulate  a 
rule-set  so  as  to  replace  a  logical  flinction  /  having  arity  fc  >  0  by 
a  predicate  /p  having  anty  fc  -I-  1,  where  inUiitively  the  (fe  -|-  l)"" 
argument  corresponds  to  the  resultof  applying  the  flinction. 


(Adv  7):  There  is  a  large  population  of  developers  (not  just 
researchers)  who  are  familiar  with  them. 

4.2     KR  Extension  to  Courteous  Logic 
Programs 

Courteous  LP's  (CLP)  expressively  extends  Ordinary  LP's 
(with  WFS)  by  adding  the  capability  to  conveniently  ex- 
press prioritized  conflict  handling,  while  maintaining  compu- 
tational tractability  (e.g.,  under  the  VBD  restriction).  CLP 
is  a  previous  KR  [10]  which  we  have  here  further  expres- 
sively generalized,  notably  to  handle  pairw'ise  mutual  exclu- 
sion conflicts,  rather  than  simply  conflicts  of  the  form  p  ver- 
sus ->p.  (Here,  ->  stands  for  classical  negation.  Intuitively,  -■p 
means  p  is  believed  to  be  definitely  false.) 

CLP  can  be  tractably  compiled  to  OLP.  Indeed,  we 
have  implemented  such  a  courteous  compiler  [II]  [13]  [12]. 
The  compiler  enables  modularity  in  software  engineering  and 
eases  implementation  and  deployment:  the  Courteous  LP  ex- 
pressive capability  can  be  added  modularly  to  an  Ordinary  LP 
rule  engine/system  simply  by  adding  a  pre-processor.  Com- 
pilation's computational  complexity  is  cubic,  worst-case,  but 
often  is  closer  to  linear. 

In  this  paper,  we  do  not  have  space  to  give  full  details  about 
the  generalized  CLP  formalism  or  its  courteous  compiler.  In- 
stead, here  we  will  give  an  overview  and  some  examples.  For 
details,  see  [12]  and  the  forthcoming  extended  version  of  this 
paper. 

CLP  handles  conflicts  between  rules  using  partially- 
ordered  prioritization  information  that  is  naturally  available 
based  on  relative  specificity,  recency,  and  authority.  Rules  are 
subject  to  override  by  higher-priority  conflicting  rules.  For 
example,  some  rules  may  be  overridden  by  other  rules  that  are 
special-case  exceptions,  more-recent  updates,  or  from  higher- 
authority  sources. 

Courteous  LP's  facilitate  specifying  sets  of  rules  by  merg- 
ing, updating  and  accumulating,  in  a  style  closer  (than  Ordi- 
nary LP's  or  than  classical  logic/KIF)  to  natural  language  de- 
scriptions. The  expressive  extension  provided  by  CLP  is  thus 
valuable  especially  because  it  greatly  facilitates  incremental 
specification,  by  often  eliminating  the  need  to  explicitly  mod- 
ify previous  rules  when  updating  or  merging.  In  terms  of  the 
rule  representation  requirements  we  gave  in  section  3,  this  en- 
ables significantly  greater  modularity,  locality,ea  se  of  modi- 
fication.e  xpressive  convenience,  and  conceptual  naturalness. 

In  CLP,  priorities  are  represented  via  a  fact  comparing  rule 
labels:  override s{rulel,  rule2)  means  that  rulel  has  higher 
priority  than  rule2.  If  rulel  and  rule2  conflict,  then  rulel 
will  win  the  conflict. 

Syntactically,  a  CLP  rule  differs  from  an  OLP  rule  in  two 
ways.  First,  it  may  have  an  optional  rule  label,  used  as  a 
handle  for  specifying  prioritization.  Second,  each  rule  literal 
may  be  classically  negated.  Syntactically,  OLP  is  simply  a 
specialca  se  of  CLP.  An  OLP  rule  lacks  a  label  and  does  not 
mention  classical  negation. 


A  CLP  rule  has  the  fomi: 
{lab)      Lo    <-    Li  A  . . .  A  Lm 

A  ~Lm+i  A  ...  A  ~L„. 
Here,  n  >  m  >  0,  and  each  I,  is  a  classical  literal.  A  clas- 
sical literal  is  a  Ibniiula  of  the  t'onn  -4  or  -i.4,  where  .4  is 
an  atom.  ->  stands  for  the  classical  negation  operator  sym- 
bol, and  is  read  in  English  as  "not",  lab  is  the  rule's  label. 
The  label  is  optional.  If  omitted,  the  label  is  said  to  be  empty. 
The  label  is  not  required  to  be  unique  within  the  scope  of  the 
overall  logic  program;  i.e.,  two  rules  may  have  the  same  la- 
bel. The  label  is  treated  as  a  0-ary  function  symbol.  The  label 
is  preserved  during  instantiation;  all  the  ground  instances  of 
the  rule  above  have  label  lab.  overrides  and  the  labels  are 
treated  as  part  of  the  language  of  the  logic  program,  similarly 
to  other  predicate  and  function  symbols  appearing  in  the  logic 
program. 

Semantically,  a  CLP  entails  a  set  of  (primitive)  conclusions 
each  of  which  is  a  ground  classical  literal.  Classical  nega- 
tion is  enforced:  p  and  -^p  are  never  both  concluded,  for  any 
(classical  literal)  p.  This  can  be  viewed  as  the  enforcing  of  an 
implicit  mutual  exclusion  between  p  and  -ip. 

In  the  newly  generalized  version  of  CLP,th  e  CLP  also  op- 
tionally includes  a  set  of  pairwise  mutual  exclusion  (mutex) 
statements,  along  with  the  rules.  These  mutex 's  specify  the 
scope  of  conflict.  An  unconditional  mutex  has  the  syntactic 
form- 

±  ■t-  Li  A  L2. 
where  each  Lj  is  a  classical  literal.  Semantically,  each  such 
mutual  exclusion  specified  by  a  mutex  is  enforced:  Li  and  L2 
are  never  both  concluded  (for  any  instantiation).  These  mu- 
tex's  are  particularly  useful  for  specifying  that  at  most  one  of 
a  set  of  alternatives  is  to  be  permitted.  E.g.,  in  Example  1 ,  it  is 
straightforward  to  specify  via  a  mutex  that  the  refund  percent- 
age must  be  at  most  one  of  the  values  {90%  ,  100%}.  E.g.,  in 
Example  2,  it  is  straightforward  to  specify  via  3  mutex 's  that 
the  lead  time  must  be  at  most  one  of  the  values  {2  days,  14 
days,  30  days}.  E.g.,  in  Example  3,  it  is  straightforward  to 
specify  via  3  mutex's  that  the  discount  percentage  must  be  at 
most  one  of  the  values  {0%,  5%,  10%}. 

It  is  expressively  more  convenient  sometimes  to  use  a  more 
general  form  of  mutex:  a  conditional  mutex,  which  has  the 
syntactic  form: 

1    ^    Li  A  L2    I    (?y  7^?Z). 
where  TV  and  ?Z  are  logical  variables  that  appear  respec- 
tively in  Li  and  ^2-  E.g., 
±    <—    giveDiscount[1Cust,  lY  Percent) 

A  giveDiscount{1Cust,  ?Z Percent) 

I    (lY Percent  ^?ZPercent). 
This  conditional  mutex  enables  one  to  specify  with  a  single 
mute.x  statement  (rather  than  with  three  or  more  unconditional 
mutex's)  that  for  a  given  customer  ICust  there  must  be  at 
most  one  value  concluded  for  the  discount  percentage. 

The  enforcement  of  classical  negation  can  be  viewed  as  a 
set  oi  implicit  unconditional  mutex's,  one  for  each  predicate 


Q,  that  each  have  the  form 

1    <-    Q(?X1, . . . ,  IXni)  A  ^g(?Xl, . . . ,  ?Xm). 
where  Q's  arity  is  m.  This  is  called  a  classical  mutex. 

Example  4  (Ordering  Lead  Time,  in  CLP) 

Example  2  can  be  straightforwardly  represented  in  CLP  as 
follows: 

(a)  order  Modi  ficationNotice{?Order,  dayslA) 

<—    preferredCustomerOf{? Buyer, '^Seller)  A 
purchaseOrder{'!Order, '? Buyer,  ? Seller). 

(b)  order  Modi  ficationNotice{?Order,  days30) 

■(—    minor Part{? Order)  A 

purchaseOrder{?Order,  ? Buyer,  ?Seller). 

(c)  or  derModificationNotice{1  Order,  days2) 

<—    preferredCustomerOfC? Buyer,? Seller)  A 
order ModificationType{? Order,  reduce)  A 
orderltemi sInBacklogilOrder)  A 
purchaseOrder{?  Order,  1  Buyer,  ISeller). 
overrides{c,a). 

±    <—    order  Modi  ficationNotice{'?Order,?X)  A 
order  ModijicationNotice{10rder,  lY) 
I   {IX  ^lY). 
To  represent  this  example  directly  as  an  Ordinary  LP  — 
while  handling  conflict  appropriately  in  regard  to  priorities 
and  guaranteeing   consistency  —  requires   modifying  the 
rules  to  add  extra  "interaction"  conditions  that  prevent  more 
than  one  rule  applying  to  a  given  purchase  order  situation. 
Moreover,  adding  a  new  rule  requires  modifying  the  other 
rules  to  add  additional  such  interaction  conditions.    This  is 
typical  of  conflicting  rule-sets  and  underscores  the  advantage 
of  the  prioritized  conflict  handling  expressive  feature  (recall 
the  discussion  of  modularity  andea  se  of  modification  in 
section  3). 

Semantically,  the  prioritized  conflict  handling  in  CLP  is 
defined  by  a  process  of  prioritized  argumentation  among 
opposing  candidates.  Opposition  is  specified  by  the  set  of 
mutex's.  Each  rule  r  whose  body  is  satisfied,  i.e.,  which 
"fires",  generates  a  candidate  c  for  r's  (appropriately  instan- 
tiated) head  p.  This  candidate  has  an  associated  label,  which 
is  simply  that  rule  r's  label.  In  general,  there  may  be  multiple 
candidates  for  a  given  p,  i.e.,  a  team  for  p.  If  and  only  if  there 
is  an  opposing  candidate  d  (i.e.,  a  candidate  for  an  opposing 
literal  q)  that  has  higher  priority  than  candidate  c,  then  c  is  re- 
futed. Suppose  there  is  an  unrefuted  candidate  for  p.  If  there 
are  no  unrefuted  candidates  for  any  opposer  of  p,  then  p  wins, 
i.e.,  p  is  concluded.  However,  it  may  be  that  there  is  an  unre- 
fiited  candidate  for  an  opposer  of  p;  in  this  case,  the  opposing 
unrefuted  candidates  skeptically  defeat  each  other.  The  con- 
flict cannot  be  resolved  by  the  specified  priority;  neither  p  nor 
its  opposer  is  concluded. 

Another  way  to  view  thisis  as  follows.  An  opposition- 
locale  is  a  set  of  /i  >  2  ground  classical  literals  that  op- 
pose each  other,su  ch  that  at  most  one  of  those  literals  is  per- 
mitted (by  the  specified  mutex's)  to  be  concluded.    In  each 


opposition-locale,  if  the  maximal-priority  candidates  are  all 
for  the  same  literal,  then  that  literal  wins. 

The  definition  of  CLP  includes  some  additional  expressive 
restrictions,  which  we  do  not  have  space  to  detail  here. 

CLP  always  produces  a  consistent  set  of  conclusions,  en- 
forcing all  the  mutex's.  CLP  also  has  several  other  attractive 
well-beha\  ior  properties,  including  about  merging  and  about 
natural  belun  ior  of  prioritization;  however,  we  do  not  have 
space  here  to  detail  these. 

The  courteous  compiler  in  effect  represents  the  priori- 
tized argumentation  process  in  OLP.  It  introduces  some  ex- 
tra "adorning"  predicates  to  represent  the  intennediate  stages 
of  argumentation:  candidates,  unrefuted  candidates,  skepti- 
cal defeat,  etc..  The  compiler  makes  it  simple  to  detect  an 
unresolved  conflict,  e.g.,  to  raise  an  alarm  about  it  in  either 
fonvard  or  backward  reasoning. 

From  the  tractability  of  courteous  compilation,  it  follows 
directly  that  Courteous  LP  inferencing  under  the  VBD  restric- 
tion is  tractable.  It  has  the  same  worst-case  time  and  space 
complexity  as:  OLP  inferencing  where  the  bound  v  on  the 
number  of  variables  per  rule  has  been  increased  to  w  -I-  2. 

Note  that  CLP  overlaps  syntactically  and  semantically  with 
KIF  for  a  broad  case.  CLP  without  negation-as-failure,  with- 
out labels  (or  ignoring  labels),  and  without  conflict,  is  syn- 
tactically a  restricted  (essentially ,cl  ausal)  case  of  first-order- 
logic  (FOL)/KIF.  Semantically,  such  CLP  is  sound  but  incom- 
plete when  compared  to  FOL/KIF,  in  that  its  entailed  conclu- 
sions are  equivalent  to  a  (conjunctive)  set  of  ground  literals. 

4.3     XML  Embodiment:  Business  Rules 
Markup  Language 

Our  approach  includes  a  second  aspect  beyond  the  funda- 
mental KR.W  e  embody  the  rule  representation  concretely  as 
XML  documents. 

Next,  we  give,  for  the  first  time,  an  XML  embodiment  of 
CLP.  Called  Business  Rules  Markup  Language  (BRML),  this 
XML  embodiment  functions  as  an  interlingua  between  het- 
erogeneous rule  representations/systems  which  different  con- 
tracting agents  may  be  employing.  BRML  inherits  the  declar- 
ative semantics  of  CLP. 

BRML  also  is  the  first  XML  embodiment  of  (declarative) 
OLP  to  our  knowledge.  Since  CLP  also  expressively  covers 
a  subset  of  KIF,  as  described  above,  BRML  is  also  an  XML 
embodiment  of  that  subset  of  KIF  —  to  our  knowledge,  the 
first  XML  embodiment  of  (any  fragment  oO  KIF. 

Figure  I  shows  the  CLP  from  Example  4  encoded  in 
BRML.  Only  the  first  rule  of  that  Example  is  shown  in  de- 
tail, "cliteral"  means  "classical  literal",  "fcliteral" 
means  a  rule  body  literal,  i.e.,  a  literal  formed  by  optionally 
applying  the  negation-as-failure  operator  outside/in-front  of  a 
classical  literal. 

In  this  paper,  we  do  not  have  space  to  give  full  de- 
tails about  the  XML  encoding.  For  full  details,  see: 
(1)   the    CommonRules    prototype   download   package   (at 


<?xml  version="l . 0"?> 
<clp> 
<erule  rulelabel="a"> 
<head> 
<cliteral  predicate= 

"orderModi£icationNotice"> 
<variable  name= "Order" /> 
< function  name="daysl4 "/> 
</cliteral> 
</head> 
<body> 
<and> 
<fcliteral  predicate= 

"preferredCustomerOf  "  > 
<variable  name= "Buyer"/ > 
<variable  name="Seller"/> 
</f cliteral> 

<fcliteral  predicate= "purchaseOrder" > 
<variable  name="Order"/> 
<variable  name = "Buyer"/ > 
<variable  name= "Seller" /> 
</fcliteral> 
</and> 
</body> 
</erule> 


</clp> 


[rest   of   rules   &  mutex's   skipped] 


Figure  1 :  XML,i.  e.,  BRML,  for  Example  4. 


http://alphaworks.ibm.com),  which  contains  the 
XML  Data  Type  Definition  (DTD)  for  BRML,  explanation  of 
it,  and  a  number  of  examples  (esp.  "orderingleadtime"  there); 
and  (2)  the  forthcoming  extended  version  of  this  paper.  The 
current  DTD  is  in  draft  form;  updates  to  it  willbe  posted  on 
the  authors'  websites.  See  [14]  for  how  BRML  fits  into  the 
larger  context  of  agent  communication  languages,  including 
the  FIPA  Agent  Communication  Language  (ACL)  draft  stan- 
dard. 

As  compared  to  the  usual  plain  ASCII  text  style  of  embod- 
iment cf  KIF  or  Prolog  or  most  programming  languages, 
the  XML  approach  has  several  advantages.  It  facilitates 
developing/maintaining  parsers  (via  standard  XML  parsing 
tools),  and  integrating  with  WWW-world  software  engineer- 
ing. XML  is  easier  to  automatically  parse,  generate,  edit, 
and  translate,  because  there  are  standard  XML-world  tools 
forth  ese  tasks.  The  hyper-text  (i.e.,  links)  aspects  of  XML 
are  also  useful.  For  example,  a  rule  set  may  via  XML  have 
some  associated  URL's  which  point  to  documents  describing 
that  rule  set's  knowledge  representation  or  authors  or  appli- 
cation context.  Or  it  may  have  associated  URL's  which  point 
to  tools  for  processing  that  rule  set,  e.g.,  to  execute  it,  edit  it, 
analyze  it,  or  validate  it  (syntactically  or  semantically).  Par- 
ticularly useful  for  our  nearer-term  purposes  is  that  an  asso- 
ciated URL  may  point  to  documents  describing  the  seman- 
tics and  algorithms  for  translator  services  or  components,  as 
well  as  to  translator  tools  and  examples.  Representing  busi- 
ness rules  in  XML  has  a  further  advantage:  it  will  comple- 


ment  domain-specific  ontologies  (i.e.,  vocabularies)  available 
ill  XML.  Many  such  ontologies  exist  already,  and  many  more 
are  e.vpected  to  be  developed  in  the  ne.\t  few  years,  including 
in  e-commerce  domains.  The  XML  approach  also  facilitates 
integration  with  Electronic  Data  Interchange  (EDI)  and  other 
e-commerce  components  that  "talk"  XML. 

We  have  implemented  sample  translators  that  go  (bidi- 
rectionally)  from  the  .\ML  interlingua  to  several  ac- 
tual rule  systems  as  proof  of  feasibility.  These  rule 
systems  include  two  previously  e.xisting  WFS  OLP 
inferencing  engines  built  by  others  and  implemented 
in  C.  One  is  exhaustive  forward-direction:  Smod- 
els  (version  I),  by  llkka  Niemela  and  Patrik  Simons, 
http  :  //saturn  .  hut:  .  f  i/html/st;af  f /ilkka  .  html. 
The  other  is  backward-direction:  XSB,  by  David  Warren 
el  al,  htitp  :  / /www  .  cs  .  sunysb  .  edu/~sbprolog. 
In  addition,  we  have  implemented  a  sample  translator  to  a 
third,  predicate-acyclic  WFS  OLP  inferencing  engine  we 
built  ourselves  in  Java.  Furthermore,  we  have  implemented  a 
sample  translator  to  ANSI-draft  KIF  (ASCII  format). 

5     Discussion  and  Future  Work 

The  implementation  of  our  approach  was  released  as  a  free 
alpha  prototype  called  CommonRules  on  the  Web  in  July 
of  1999,  al  http : //alphaworks  .  ibm.com.  This  pro- 
totype is  a  Java  library  that  includes  both  the  CLP  and  the 
BRML  aspects  of  ourapp  roach.  In  particular,  it  includes  a 
courteous  compiler  and  sample  translators  between  BRML 
and  several  other  rule  systems/languages. 

In  summary,we  believe  our  approach  combining  CLP  and 
XML  meets  the  whole  set  of  requirements  we  gave  in  sec- 
tion 3  better  than  any  previous  approach.  Indeed,  we  believe 
our  approach  meets  every  one  of  those  requirernents  to  a  sig- 
nificant degree,  with  one  exception:  the  ability  to  express  pro- 
cedural attachments. 

The  usefulness  of  rules  in  a  declarative  KR  for  represent- 
ing executable  specifications  of  contract  agreements  is  based 
largely  on  their  following  advantages  relative  to  other  soft- 
ware specification  approaches  and  programming  languages. 
First,  rules  are  at  a  relatively  high  level  of  abstraction,  closer 
to  human  understandability,  especially  by  business  domain 
experts  who  are  typically  non-programmers.  Second,  rules 
are  relatively  easy  to  modify  dynamically  and  by  such  non- 
programmers- 

In  current  work,  we  are  expressively  generalizing  fur- 
ther to  Situated  Courteous  LP's,  so  as  to  enable  procedu- 
ral attachments  as  well  —  in  a  semantically  clean  manner 
(i.e.,  declaratively  in  a  particular  well-defined  sense).  Situ- 
ated LP's[9]  [16]  [15],  another  expressive  extension  of  Ordi- 
nary LP's,  hook  beliefs  to  drive  procedural  APIs.  Procedu- 
ral attachments  for  condition-testing  ("sensing")  and  action- 
performing  ("effecting'')  are  specified  as  part  of  the  knowl- 
edge representation:  via  sensor  and  effector  linl<  statements. 


Each  sensor  or  effector  link  associates  a  predicate  with  an  at- 
tached procedure.' 

In  current  work,  we  are  also  expressively  generalizing  CLP 
and  BRML  further  to  relax  expressive  restrictions  such  as  on 
cyclicity/recursion  restriction,  e.g.,  to  be  stratified  rather  than 
predicate-acyclic. 

There  are  several  other  formalisms  for  prioritized  LP's  that 
have  similar  syntax  to  Courteous  LP's  (except  for  lacking  mu- 
tex's)  but  different  semantics  in  regard  to  conflict  handling 
(see  [10]  [II]  for  a  review).  A  direction  in  our  current  work 
is  to  explore  this  dimension  of  heterogeneity.  None  of  these 
other  fonnalisms  to  our  knowledge  has  as  attractive  a  combi- 
nation of  useful  expressive  power,  software-engineering  mod- 
ularity, well-behavior  (e.g.,  consistency,  unique  set  of  conclu- 
sions), tractability,  and  conceptual  simplicity  (e.g.,  in  prioriti- 
zation behavior  and  merging).  In  particular,  none  can  express 
mutex's  (besides  implicit  classical  mutex's),  and  none  has  a 
compiler  to  OLP's. 

There  are  other,  more  expressively  powerfiil  approaches  to 
prioritized  default  reasoning  such  as  Prioritized  Default  Logic 
[2]  and  Prioritized  Circumscription  [19]  [18]  [7]  [8]  that  es- 
sentially can  express  mutex's,  but  in  these  the  prioritized  con- 
flict handling  imposes  computationally  intractable  overhead 
[6]. 

It  appears  fairly  straightforward  to  extend  our  BRML  DTD 
in  stages  so  as  to  express  full  first-order  logic  and  then  full 
KIF.  A  direction  for  future  work  is  to  create  a  DTD,  maxi- 
mally compatibly  with  BRML,  that  expresses  full  KIF. 

In  other  work  [21],  we  have  extended  our  contract  rule 
representation  approach  with  negotiation  features  oriented  to- 
wards automatic  configuration  of  auctions,  including  to  spec- 
ify which  attributes  of  a  contract  are  to  be  the  subject  of  ne- 
gotiation or  bidding. 

Of  course,  there  is  yetm  ore  to  do  to  fiilfill  our  approach's 
promise,  and  achieve  its  ultimate  goals.  Further  issuesfo  r 
fiiture  work  include:  meshing  more  closely  with  other  as- 
pects of  contracts,  e.g.,  transactions,  payments,  negotiation 
and  communication  protocols  [5]  [20],  EDI,  and  utility/cost- 
benefit;  fleshing  out  the  relationships  to  a  variety  of  com- 
mercially important  rule  representations/systems;  represent- 
ing constraints  as  in  constraint  satisfaction  and  Constraint 
Logic  Programs;  and  representing  delegation  as  in  secu- 
rity/authorization policies  [17]. 

An  extended  version  of  this  paper  will  be  avail- 
able as  a  forthcoming  IBM  Research  Report  (at 
http  :  //www.  research  .  ibra.  com). 
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